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REMARKS 



In response to an Office Action mailed on April 29, 2004, 
Applicant respectfully requests that the above-listed Amendments 
be entered and the Application ' be reconsidered in light of the 
following remarks. With entry of the above-listed Amendments, 
claims 1, 10 and 19 are amended; claims 2, 11 and 20 are canceled; 
and claims 3-9, 12-18 and 21-27 are original. Thus, 24 claims are 
presented for examination. Of these, claims 1, 10 and 19 are 
independent, and the remaining claims are dependent. 

The Examiner rejected Claims 1-27 under 35 0-S.C. 103(a) as 
being obvious over US Pat. "No. 6,545, 982 to Murphy, et al. 
P Murphy") in view of US Pat. No. 6,580,715 to Bare pBare")- The 
Applicant notes that the third paragraph on page 3 of the Office 
Action refers to a third reference ("Muller" ) , however Paragraph 3 
of the Office Action does not list Muller. On July 23, 2004, the 
undersigned telephoned the Examiner to seek clarification of this 
apparent discrepancy. The Examiner advised that the reference to 
Muller is a typographical error, and that this reference should be 
interpreted as being to Murthy. The reference to Muller is so 
interpreted hereinbelow . 

Murthy discloses a multi-port, packet-based bridge that 
supports monitoring of data packets that are received over one or 
more designated ports of the bridge* Murthy' s system sends copies 
of the data packets to a specially designated monitoring port, as 
well as forwarding the packets to their respective destinations, 
as indicated by their respective destination addresses- Thus, 
Murthy' s system allows packet traffic arriving over several ports 
to be monitored simultaneously at a single port, i.e. the 
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.onitorinc, port, by meeting a monitoring devics to the 

monitoring port. 

Bare discloses a switch-to-switch protocol for network load 
balancing. The protocol provides a specially formatted «hello" 
packet that is periodically sent cut over all ports of a "load 
balance" switch to inform remote load balance switches that a load 
balance switch exists on the other end of a link. Hello packets 
are also used to detect illegal topologies. (C16, L57 to C17, L4.) 

The Examiner cited Murthy (C6, 132-59) as disclosing 
"monitoring an intra-hub communication path of a network hub to 
detect a first data unit on said intra-hub communication path 
having a destination address matching a first predetermined 
address," as recited in claim 1. J 

First, it is believed that Murthy does not disclose "an 
intra-hub communication path ." As shown in Figure 1, Murthy' s 
bridge 1 includes ports 3 (numbered 0-5) . The bridge examines and 
evaluates packet transmissions on its ports. (C6, L35-36, emphasis 
added.) Nowhere, however, does Murthy show "an Intra-hub 
communication path of a network hub." In contrast, the present 
Application discloses an intra-hub communication path. For 
example, in the embodiment shown in Fig. 1, Bridges A, B and C 
(16, 18 and 19) are interconnected by a Switching Fabric 14 and 
three point-to-point connections 12, 13 and 15- 

Second, it is believed that Murthy does not disclose 
"monitoring ... to detect a first data unit ... having a 
destination address matching a first predetermined address." In 
the portion cited by the Examiner, Murthy discloses forwarding 
certain received packets (i.e., packets that have the 
Broadcast /Multicast flag 21 (Figure 3) set to one) to all attached 
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ports, except the ports on which the packets were received. It is 
believed that a -first predetermined address/' as recited in claim 
1, does not read on a destination address that has the 
Broadcast/Multicast flag 21 set to a one, because many different 
destination addresses can have this flag set to a one. As Murthy 
describes at C5, L28-38, if the remaining bits of the destination 
address (the Broadcast /Multicast address 24 (Figure 3)) are all 
ones, then the destination address is considered to designate all 
stations in the network. On the other hand, if the remaining bits 
of the destination address ' are not all ones, the remaining bits 
signify a subset of stations in the network that are destinations. 
Since there can be many bit patterns (that are not all ones) in 
the remaining bits of the destination address, the remaining bits 
of the destination address can specify many different subsets of 
stations. Thus, Murthy does not disclose "monitoring ... to detect 
a first data unit - - - having a destination address matching a 
first predetermined address." 

The Examiner cited Murthy (C7, L34-40) as disclosing * storing 
a source MAC address of said detected first data unit/' as recited 
in claim 1. In the portion cited by the Examiner, Murthy discloses 
adding a new entry to a Bridging Table 25, if the source address 
16 of a received packet does not match a Station Address field 27 
of any existing Bridging Table entry 26. In other words, Murthy 
describes how a bridge "learns" the correspondence between 
attached stations and the ports to which they are attached. (C7, 
L44-46.) There is no connection between the detection of the 
Broadcast/Multicast flag 21 described above and this learning 
activity. The detection of the Broadcast/Multicast flag 21 does 
not trigger the storage of the source MAC address in the Bridging 
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Table. In Murthy, these two activities are completely independent 
of one another. In contrast, the claim recites, -storing a source 
MAC address of sai^ detected first data unit/' i.e. there is a 
connection between detecting the first data unit and storing the 
source MAC address of the detected first data unit. 

The Examiner cited Murthy (C9, L4-B) as disclosing 
-monitoring said plurality of external communication ports to 
detect a second data unit having a destination address matching 
said first predetermined address received at a respective one of 
said plurality of external communication ports/' as recited in 
claim 1- However, the portion of Murthy cited by the Examiner 
merely reiterates some of the forwarding capabilities of a bridge, 
for example * [f ] orwarding of multicast and broadcast packets to 
more than one port and possibly all ports." Nowhere does Murthy 
disclose "monitoring said plurality of external communication 
ports to detect the second data unit having a destination address 
matching said first predetermined address received at a respective 
one of said plurality of external communication ports/' 

The Examiner cited Bare (C 20, L6-20) as disclosing "in the 
event that said source MAC address of said second detected data 
unit matches said stored source MAC address, disabling operation 
of said respective one of said plurality of external communication 
ports at which said second detected unit was received/' as recited 
in claim 1. Bare uses hello packets to detect illegal topologies. 
(C16, L57 to C17, L4.) 

Bare's hello packet is of an entirely different format than 
the recited first and second data units. All of Bare's load 
balancing switch-to-switch packets, including hello packets, use a 
unicast packet format, in which the destination MAC address 402 
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(Fig. 4) is set to a unique destination MAC address . (C14, Lll- 
18.) Thus, each hello packet is addressed .to a single, unicas t 
address. In contrast, in the presently disclosed system, the 
destination address in the detected first data unit is a bridge 
multicast address, as recited in amended claim 1. 

Although Bare discloses a protocol for detecting loops, Bare 
relies on the specially formatted hello packet 500 to detect these 
loops, and Bare's system uses the hello packets differently than 
the claimed invention uses the recited first and second data 
units, in Bare's system, if two ports of a switch are connected to 
each other (such as by a loop formed by a hub connected to the two 
ports), hello packets sent out by the switch over one of the ports 
return to the switch over the other port. Upon receiving the 
returned hello packets, the switch recognizes the packets and 
blocks one of the ports. (C19, L59-65.) Hello packets are, 
however, considerably different than the first and second data 
units recited in amended claim 1. 

The hello packet contains a source MAC address that is unique 
to each port, rather than the switch's MAC address. Thus, a non- 
load balance switch that forms a loop with one of Bare's switches 
does not see identical switch addresses in hello messages it 
receives from different ports of Bare's switch. According to Bare, 
this is done to prevent shutting down at least one of the ports. 
(C17, L7-20.) In contrast, in the presently disclosed system, the 
source MAC address is either the MAC address of the switching 
fabric within the network hub (i.e. the switch' s MAC address) or a 
source address contained in a bridge protocol data unit (BPDU) 
that is received from another switch or hub. (Application: Pll, 
L28 to P12, L9.) In the presently disclosed system, the switch's 
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MAC address is used so that loops can be detected and shutdown. 
Thus, Bare teaches away, from the presently disclosed invention. 

Furthermore, the claim clause that the Examiner cited as 
reading on Bare (C20, L6-20) recites a - second detected data 
unit/' however Bare does not disclose monitoring to detect a 
seco nd data unit having a destinatio n address matching a first 
predetermined address. Bare' s system detects hello packets based 
on a switch ID" 506 (Fig. 5), which is separate from both the 
source address 404 (Fig. 4) and the destination address 402. (See, 
C19, L59-64) Thus, Bare does not disclose any, processing that 
involves a - second detected data unit," as recited in claim 1. 

Thus, no art of record, either alone or in combination, 
discloses or suggests a method for preventing bridge loops, as 
recited in amended claim 1. For at least this reason, claim 1 is 
believed to be allowable - 

Claims 3-9 depend directly or indirectly from claim 1. Claims 
3-9 are, therefore, believed to be allowable, for at least the 
reasons discussed above with respect to claim 1- 

The Examiner rejected claims 10-18 under the same rationale 
as claims 1-9. As discussed above respect to claim 1, the art of 
record, either alone or in combination, does not disclose or 
suggest apparatus for eliminating loops, as recited in amended 
claim 10. Claims 12-18 depend directly or indirectly from claim 10 
and are, therefore believed to be allowable, for at least the 
reasons discussed above with respect claim 10. 

' The Examiner rejected claims 19-27 under the same rationale 
as claims 1-9. As discussed above respect to claim 1, the art of 
record, either alone or in combination, does not disclose or 
suggest a system for eliminating loops, as recited in amended 
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claim 19. Claims 21-27 depend directly or indirectly from claim 19 
and are, therefore believed to be allowable, for at least the 
reasons discussed above with respect claim 19- 

For all the foregoing reasons, it is respectfully submitted 
that the present Application is in a condition for allowance, and 
such action is earnestly solicited. The Examiner is encouraged to 
telephone the undersigned attorney to discuss any matter that, 
would expedite allowance of the present Application. 

Respectfully submitted, 
CARL JOHN LINDEBORG ET AL. 




Georfife J/ zrakobsche 
Regi^rdtion No- 39,236 
: Attorney for Applicant (s) 

WE I W G ART £N , SCHURGIN, 

GAGNEBTN 6 LEBOVICI LLP 
Ten Post Office Square 
Boston, MA 02109 
Telephone: (617) 542-2290 
Telecopier: (617) 451-0313 
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